Transactions typically involve multiple parties, including a user (e.g., consumer), a merchant, an acquirer bank, and an issuer bank. While each user (e.g., a consumer), acquirer bank, and issuer bank may have a unique identifier (e.g., an account number, a bank identification number [BIN]) that may be consistently used, merchants typically do not have a single defined or unique identifier.
For example, a merchant may be identified by a merchant category code (MCC), a merchant name (e.g., “Big Box Store”), a merchant location (e.g., “Big Box Store—San Francisco”, “Big Box Store Location #1293”), or a specific location within the merchant location (e.g., “Electronics Counter—Big Box Store Location #1293”). Increasing the difficulty is that in some cases, a merchant name and merchant location (e.g., city, state, zip code) may be free form text fields. The result may be that the merchant name for a single merchant may be different for different entities and systems.
FIG. 2 illustrates the current problem with how different entities and systems may use different designations for a merchant name associated with the same merchant location. Each row represents a merchant name associated with a single transaction, where each column is a different system (e.g., acquirer, issuer, payment processing network). The Raw Merchant Name 202 column illustrates the raw merchant name that may be in the transaction data (e.g., from an acquirer computer). Columns 204, 206, 208, 210, and 212 illustrate how the raw merchant name received in the transaction data may be translated/interpreted by a plurality of different systems.
The problem illustrated in FIG. 2 can make it difficult to accurately correlate related transactions and provide comprehensive analytics for a merchant. Even determining how many transactions were processed for a merchant may be difficult to ascertain because the merchant name data may not be consistent across a plurality of systems. In some situations, even internally, a system (e.g., System 3 208 in FIG. 2) may have different naming conventions for the same overall merchant (e.g., Big Box). For example, if you queried System 2 206 to determine how many transactions involved merchant “Big Box”, it may not present the first and third transactions in FIG. 2, while if you sent the same query to System 5 212, all three transactions in FIG. 2 may be presented.
Even where merchant data is consistent, it may be able to provide limited value. For example, presently, merchant location data associated with a transaction is often limited to a zip code for the merchant location, which may provide only limited location information. While in some areas, zip codes may cover a relatively small and defined area (e.g., zip code 11109 covers 0.01 square miles), while other zip codes may cover a large region (e.g., zip code 89049 covers 1740 square miles). In the latter situation, the merchant zip code may not provide significantly valuable location information.
Embodiments of the invention address the above problems, and other problems, individually and collectively.